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METHOD FOR MULTfflOP ROUTING FOR 
DISTRIBUTED WLAN NETWORKS 

RELATED APPLICATIONS 

5 This application claims priority from and incorporates herein by reference 

the entire U. S. Provisional Application Serial No. 60/326,059, filed on September 
27, 2001. 

BACKGROUND OF THE INVENTION 
FIELD OF THE INVENTION 

10 The present invention relates to distributed wireless local area networks, 

and more particularly, to a method for more efficiently transmitting data within a 
wireless local area network system using a multihop mechanism. 
DESCRIPTION OF THE RELATED ART 

The IEEE (802.11) wireless local area network (WLAN) system enables 

15 communication between Stations (ST As) and an Access Point (AP) in an 
infrastructure system or an infrastructure less system (also called Independent BSS 
or ad hoc network mode). The IEEE 802.11 WLAN system enables single hop 
communication between STAs in BSS (Independent Basic Service Set) mode. 
The access mechanism is a distributed mechanism called Distributed Coordination 

20 Function (DCF) and is based on CSMA/CA (Carrier Sense Multiple Access/ 
Collision Avoidance). In addition to physical CS (Carrier Sense), a virtual CS 
mechanism is used such that a duration value indicates the length of the 
transmission for each transmitted packet. 

Note that a packet may constitute of one or multiple fragment to decrease 

25 the risk of packet retransmissions in the case of e.g. interference, where each 
fragment of a packet is sent after a SIFS (Short Interframe Space) after an 
acknowledgement from the receiver indicating the successful reception of previous 
fragment. The duration value sent in a fragment covers the time to transmit the 
subsequent fragment, if present, plus its corresponding ACK. 

30 Stations receiving the duration value shall not transmit on a wireless media for a 
period of time equal to the duration value stored in a duration field. In order to 
handle the so called hidden terminal problem a RTS/CTS mechanism is used. 
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Presently, multihop support for 802.11 IBSS networks (ad hoc networks) is 
not available. Multihopping enables stations out of direct reach from each other to 
communicate through relaying packets via intermediate stations. An additional 
benefit with multihop support is that by dividing a distance into multiple hops, each 
5 hop experiences significantly improved signal reception quality thanks to the 
power law propagation model. This can be exploited through the usage of a higher 
link rate that under certain conditions may even reduce the end to end delay. 

While the 802.11 protocol does not inherently support multihopping, it does 
not exclude higher layer protocols with multihop support from being placed on top 

10 of existing 802.11 protocols. Currently, the MANET WG in IETF is working on 
extensions to the TCP/IP protocol suite for mobile ad hoc networks with multihop 
capabilities. Several MANET protocols such as AODV and DSR have been tested 
with the 802. 1 1 protocol operating in the IBSS mode. 

However, when these routing protocol are used above the 802.11 protocol 

15 to provide multihop routing in the ad hoc network without any connection to the 
radio access protocol, performance problems will arise. For example, when a 
packet has to travel multiple hops between wireless stations to reach a destination, 
severe delays may arise due to the nature of the wireless protocol. Collisions can 
also occur on each link, and the access delays on each hop can add up. In order to 

20 achieve a high throughput for TCP transactions perceived by the end user, delay 
will comprise a vital factor. Thus, enabling control of multihop packets within the 
802. 1 1 protocol would greatly enhance overall network performance. 

SUMMARY 

25 The present invention overcomes the foregoing and other problems with a 

method for multihop packet transmissions in a wireless network wherein the route 
comprising a plurality of hops is initially established in the wireless network. 
Transmission protocol parameters associated with the multihop route are altered in 
order to minimize delays for packet transmissions over the multihop route. Packets 

30 are transmitted over the multihop route according to the altered transmission 
protocol parameters. 

In a first embodiment, the step of altering the transmission protocol 
parameters includes setting a NAV value at each node over the multihop route for 
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the duration of the packet transmissions over the multihop route. In an alternative 
method, multihop packets are transmitted over the multihop route according to a 
higher QoS value. 

5 BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are included to provide a further 
understanding of the invention and are incorporated in and constitute a part of this 
specification, illustrate embodiments of the invention that together with the 
description serve to explain the principles of the invention. In the drawings: 
10 Fig. 1 illustrates the establishment of a multihop connection between a first 

unit and a second unit in separate D3SS; 

Fig. 2 is a flow diagram illustrating the method for implementing a reactive 
routing protocol according to the present invention; 

Fig. 3 illustrates implementation of a first embodiment of the present 
15 invention; 

Fig. 4 illustrates an alternative embodiment of the present invention; 
Fig. 5 illustrates a further embodiment of the present invention wherein a 
prediction of when data is to be transmitted is used; and 

Fig. 6 illustrates yet a further embodiment of the present invention using a 
20 high priority access configuration. 

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 

Referring now to the drawings, and more particular to Fig. 1, where there 
are illustrated a number of STAs 10 within three separate IBSSs 15. Fig. 1 

25 illustrates a multihop connection between STA A and STA B. The connection 
ultimately includes three hops between STA A and STA B using two other STAs 
10 in order to establish the connection. According to the present invention, an 
addition is proposed to the IEEE 802.1 1 protocol. In this proposal, the NAV value 
at STA nodes within multihop route are expanded to cover a chain of hops between 

30 multiple STAs rather than only covering a single link. The NAV value protects 
transmissions from collision and interference. In this manner, once a multihop 
route has been established between two STAs 10, the delays for transmitting the 
payload will be relatively short. 

-3- 
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By extending the NAV value to cover multiple links, the overall capacity of 
the system will be decreased due to the fact that a larger part of the BSS bandwidth 
is granted to one packet transmission for a longer time period. However, in most 
cases only two or three hops may be required for a transmission so the capacity 
5 reduction does not last for an extended time period. 

Referring now also to Fig. 2, there is illustrated a flow diagram describing 
the method for implementing the routing protocol of the present invention using the 
amended NAV value as described above. Initially, at step 30, STA A has a packet 
to send to STA B. A route request message is transmitted at step 35 from STA A 

10 to a next STA 10 in a first hop of the multihop connection. The route request 
message is forwarded to a second STA 10 at step 40, and a determination is made 
at step 45 of the shortest path from the present STA 10 back to the STA A. The 
determination of the shortest path is measured with a predetermined cost metric 
such as number of hops, accumulated path loss, experienced interference 

15 resistance, delay due to busy wireless medium, etc. Additionally, at step 50, the 
reciprocal value of the link delay is accumulated along the pathway as the link rate 
may differ over each hop between STA A and STA B. 

On the third hop link, the route request message is forwarded at step 55 to 
STA B. The provided route request message includes accumulated information 

20 concerning the number of intermediate nodes between STA A and STA B (in this 
case two), the shortest path back to STA A as well as the overall end to end link 
rate accumulated from the possible link rate over each hop between STA A and 
STA B. STA B uses the accumulated information received in the route request 
message to calculate, at step 60, a duration value that represents the transmission 

25 time from STA A to STA B for a packet. The duration value represents the time to 
complete a multihop transmission. STA B returns, at step 65, a routing response 
message including the calculated duration value within a duration field. The 
duration field may also include a repetition interval and a path determination time. 
The repetition interval and path determination time allows a path to be established 

30 in a repetitive manner for traffic having repetitive structure such as voice. In order 
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for the route reply message to convey appropriate duration and repetition values, 
the route request message carries information of the packet length, parameters for 
any repetitive structure. In addition, each STA ensures that the medium will be 
available as asked for in a route request message containing e.g. parameter(s) for a 
5 repetitive use of the medium as other medium repetition may be executed by 
neighboring STAs. 

The routing response message is forwarded at step 70 from the first 
intermediate STA 10 to the next STA 10 along the previously used multihop route. 
STAs within the multihop route use the duration value to set, at step 75 , the NAV 

10 value at each STA 10 within the multihop link. This causes an STA 10 to refrain 
from transmitting for a period of time indicated by the duration value. Since the 
duration value represents the time to complete the packet transmission from STA 
A the NAV value prevents transmission for multiple hops rather than just a single 
hop. The routing response message is forwarded at step 80 back to STA A, and 

15 STA A transmits the packet or packets protected by the NAV value settings at each 
STA 10 back to STAB. 

Referring now to Fig. 3, there is further illustrated the method described 
with respect to Fig. 2 wherein a packet is transmitted according to the method of 
the present invention from STA A to STA B over a four hop link using three 

20 intermediate STAs 10. As described previously in steps 35, 40 and 55, the route 
request message 100 is transmitted over multihop link 105 to STAB. The route 
response message 110 is transmitted back from STA B to STA A over multihop 
link 1 1 5. In order to reduce path setup time and minimize delay variation, a highly 
prioritized route request and route reply message protocol may be used with respect 

25 to the initial transmissions between STA A and STA B in a further embodiment. 

At each STA including STA B from which the route response message 
originates, the duration value within the duration field is used to set the NAV value 
for the STA for the period of time necessary to transmit the data packet from STA 
A to STA B. Once the route response 1 10 has been received back at STA A and 

30 the NAV settings 120 have been set for each intermediate STA 10, the packet or 
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packets from STA A may be transmitted to STA B. The transmission occurs from 
STA to STA in a data transmission and acknowledge process 125. Thus, the 
packet or packets are initially transmitted from STA A over the first hop to the first 
STA 10a, and STA A receives an acknowledgment of receipt of the packet or 
5 packets. This process continues until the packets are finally received and 
acknowledged by the STAB. Finally, STAB send an ETE acknowledge message 
130 back to STA A to indicate receipt of the packet or packets at STA B. After 
receipt of the acknowledgment message 130 at STA A, the NAV settings will 
return to normal and the STAs 10 may continue transmissions. 

10 In an additional step, the NAV value may be cleared along the path between 

STA A and STA B if the transmission from STA A to STA B cannot be completed 
for some reason or if the transmission is completed prematurely. In this case, an 
additional clear message may be transmitted from STA A to STAB to clear each of 
the NAV values within the STA 10. 

15 In a further alternative to the method described in Fig. 2, rather than 

determining the route from STA A to STA B during transmission of the route 
request response to message 100, the route may be determined in an earlier route 
determination process. In this case, the sole task of the route request message 100 
would be to allocate a medium along the multilink path between STA A and STA 

20 B for a specific time by setting the NAV value and would not be required to 
determine the path route. 

In a further alternative, entire knowledge of the end to end delays between 
STA A and STA B may be utilized from an earlier route determination process, and 
the route request message may include a duration value covering the duration of the 

25 entire communication between STA A and STA B including transmission of the 
route request, route response, data acknowledge and acknowledgment messages. 

In a further embodiment illustrated in Fig. 4, the first route request 100 may 
use a duration value based upon an earlier measurement of the duration from STA 
A to STA B or based upon a prediction of the round trip time from STA A to STA 

30 B. This information is used to set the NAV value at intermediate STAs during 
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transmission of the route request message to enable quicker return transmission of 
the route response message 115 from STA B to STA A. The remainder of the 
process operates in the same manner as described with respect to Fig. 3. The route 
request message 100 can always perceive delays due to a busy wireless media on a 
5 link on the way to STA B. Along the link path 105 to STA B the duration value is 
used to set the NAV value that prevents transmissions in the current IBSS. If the 
duration value is long enough, the route response message 115 will perceive no 
busy media on the return path and decrease the latency for the data deliverance 
from STA A to STAB. 

10 In yet a further embodiment illustrated in Fig. 5, the route request message 

100 is transmitted to STA A from STA B over multihop link 105 as described with 
respect to Fig. 3. However, the duration value information within the route 
response message 110 over multi hop link 115 is used in a slightly differing 
fashion. Instead of setting the NAV value settings to prevent transmissions from 

15 an STA from the point that the route response message 1 10 is received at an STA 
10 until completion of transmission of the data from STA A and receipt of the ETE 
acknowledgment message 130, information within the duration value is used to 
make an estimate of the point at which the data packet or packets will be received 
at a particular STA 10 over the multi hop link, and the NAV value is only set at this 

20 point until completion of the transmission. This enables the IBSS to be used for 
transmission of other data until data from STA A is actually received at an STA 10. 
Thus, with respect to the transmission link between STA 10b and STA B, data may 
be transmitted over the entire time period 165 until the NAV value settings were 
set at point 170. Once the data and acknowledgment procedure 125 begins 

25 between two particular STAs, the procedure is the same as described with respect 
to Fig. 3. 

The idea is thus to utilise the time until the packet in the multihop flow 
reaches the hop between e.g. 10b and STAB. 

The total delay for the RREQ message consists of contention time to win 
30 access to the airlink, transmission time (including a possible retransmission), 'relay 
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time' in each STA 10 until it is ready to start contention and so forth along the 
multihop flow. To predict when the packet reaches STA 10b, detailed information 
from each hop must be included in the RREQ and RRESP. It is then a question 
whether contention delay for one hop will be present or not, and whether 'relay' 
5 delay was due to a temporary load on the processing parts for a STA 10. Maybe 
each STA could insert its own typical 'relay' delay in the RREQ. So at least a 
minimum time could be estimated. Thus, details from each hop including airlink 
delay, and STA relay processing time are included in the RREQ and RRESP 
message. An estimation is then made at each STA 10 when data can arrive at the 
10 earliest time. 

In yet a further embodiment illustrated with respect to the flow diagram in 
Fig. 6, the protocol would initially set up a route between STA A and STA B by 
transmitting a route request message at step 180 from STA A to STA B and 
receiving at step 185 the route response message 1 10 from STA B at STA A. The 

15 protocol next determines at step 190 whether or not the packet to be transmitted 
from STA A to STA B is a multihop transmission requiring the use of a high 
priority access mechanism. Determination of whether or not a packet is to be 
transmitted with multiple wireless hops may be done in a number of fashions 
including but not limited to analyzing the four address fields of the MAC header of 

20 the packet to determine whether the source and destination addresses are members 
of the same IBSS. Members of different IBSS base would utilize the high priority 
access mechanism. Alternatively, a new information field may be inserted into the 
MAC header indicating that the packet is a multihop transfer requiring a higher 
QoS class. 

25 However the determination is made, once it is determined that a multihop 

transfer of the packet is required, the packet is given a higher QoS class at step 200 
than would normally be the case for a non-multihop packet. This enables the 
packet to be more quickly transmitted over the multihop link. Otherwise, the QoS 
remains unchanged and the packet is transmitted in the normal fashion at step 205. 
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It is believed that the operation and construction of the present invention 
will be apparent from the foregoing description and, while the invention shown and 
described herein has been characterized as particular embodiments, changes and 
modifications may be made therein without departing from the spirit and scope of 
5 the invention as defined in the following claims. 
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What is claimed is: 

1. A method for transmitting multihop packet transmissions in a wireless 
network, comprising the steps of: 

5 establishing a multihop route through a wireless network; 

altering a transmission protocol parameters to minimize delays for packet 
transmissions over the multihop route; and 

transmitting at least one packet over the route according to the altered 
transmission protocol parameters. 

10 

2. The method of Claim 1, wherein the step of altering further comprises 
. the step of setting a NAV value at each node of the route for a duration of the 

packet transmissions over the route. 

15 3. The method of Claim 2, wherein the step of establishing further 

comprises the steps of: 

transmitting a route request message requesting the multihop route from a 
first node to a second node; 

gathering route data related to the route as the first message travels from the 
20 first node to the second node; and 

transmitting a route response message back to the first node from the 
second node. 

4. The method of Claim 3, wherein the step of altering further comprises 
25 the steps of: 

calculating a duration value indicating an amount of time necessary to 
complete the multihop packet transmission responsive to the gathered route data; 
including the duration value in the route response message; and 
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wherein the NAV value is set at each node of the multihop route responsive 
to the duration value and remains set for a period of time indicated by the duration 
value. 

5 5. The method of Claim 4, further including the step of resetting the NAV 

value after completion of the transmission. 

6. The method of Claim 4, wherein the step of transmitting further includes 
the step of transmitting at least one packet over the route from the first node to the 

1 0 second node while the NAV value is set. 

7. The method of Claim 4, further including the step of resetting the NAV 
value if the transmission ends prior to a time indicated by the duration value. 

15 8. The method of Claim 4, wherein the step of establishing further includes 

the step of determining the multihop route from a previous route determination. 

9. The method of Claim 4, wherein the duration value is determined from a 
previous transmission and included in the route request message. 

20 

10. The method of Claim 3, wherein the steps for transmitting are 
transmitted according to a high priority. 

11. The method of Claim 3, further including the steps of: 

25 determining a second duration value, the second duration value equal to a 

determined transmission time from the first node to the second node; and 

setting the NAV value responsive to the duration value until completion of 
the route response message. 
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12. The method of Claim 2, wherein the NAV value is only set once a node 
begins to receive a packet transmission. 

13. The method of Claim 1, wherein the step of altering further comprises 
5 the step of establishing a higher QoS class for a multihop packet. 

14. The method of Claim 13, further including the step of determining if a 
packet is a multihop packet. 

10 15. The method of Claim 14, wherein the step of determining further 

comprises the step of analyzing address fields of a MAC header of the packet to 
determine if a source and destination address are in a same IB SS. 

16. The method of Claim 14, wherein the step of determining further 
15 comprises the step' of identifying a data field in the MAC header of the packet 
indicating a multihop packet. 
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